UltraWarm for Amazon Elasticsearch Serviceのストレージ要求と料金の計算 #reinvent

UltraWarmはre:Invent 2019期間中に発表された、Amazon Elasticsearch Serviceのコスト効率を最大化するためのサービスです。従来の構成の最大約90%のコスト削減が見込めると発表されています。開発ドキュメントに計算方法などが公開されていましたので、読みながら実際に計算してみました。

AWS re:Invent 2019

#UltraWarm

#Amazon S3

#Amazon Elasticsearch Service

#AWS

諏訪悠紀

2019.12.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

コスト削減することが目的ならば、計算してみよう

UltraWarmはre:Invent 2019期間中に発表された、Amazon Elasticsearch Serviceのコスト効率を最大化するためのサービスです。従来の構成の最大約90%のコスト削減が見込めると発表されています。

また、セッションもありましたので聴講しました。どのくらいのストレージ容量で使う想定で、どのくらいコストダウンが見込めるかを計算することが大事であることを学びました。

開発ドキュメントに計算方法などが公開されていましたので、読みながら実際に計算してみたいと思います。

現時点で一般公開されているドキュメントの情報を元に計算を行なっています。GA（一般リリース）されるなど、今後料金体系が変更される可能性がありますのでご了承ください。

ストレージ要求の計算

Hot Storageでは、データには多くのオーバーヘッド（レプリカ、Linuxの予約領域、Elasticsearchの予約領域など）が発生します。例えば1つのレプリカシャードを含む10GiBのプライマリシャードでは、Hot Storageとしては26GiBの領域が必要になります。

Ultra Warmでは、内部的にAmazon S3を使っているため上記のようなオーバーヘッドが発生しません。そのためUltra Warm Storageの計算はプライマリシャードのサイズのみを考慮すればOKです。また、Amazon S3にデータを保存するということは耐久性がAmazon S3の性能で担保されることを意味します。つまりレプリカの考慮を特別に行う必要性が無くなります。また、OSまたはサービスに関する配慮事項も取り除くことができます。

料金計算が楽になるという点も、Ultra Warmを使うベネフィットの一つですね。

Ultra Warmの価格設定

Hot Storageでは、プロビジョニングしたものに対して料金を支払う必要があります。一部のインスタンスにはAmazon EBS Volumeが必要で、その他のインスタンスにはインスタンスストアが含まれています。ストレージを使う・使わないに関わらず、プロビジョニングした分だけ料金を支払います。

Ultra Warmでは、使った分だけ料金を支払います。例えば最大20TBの ultrawarm1.large.elasticsearch インスタンスを使って1TiBのデータのみ格納していた場合、実際に支払うのは1TiB分の料金になります。また、他のすべてのノードタイプと同様に、各UltraWarmノードに対して時間料金も支払います。

特にストレージに支払う料金は、Ultra Warm Storageを使う場合の方が圧倒的に効率が良く安くなることが分かります。しかし支払う必要があるのはストレージだけではありません。ノードの時間料金も発生する点に気をつけましょう。

料金を計算してみる

いずれも60TiBのデータを格納したい場合を考えます。

Hot Storageの場合

まずHot Storageのみで構成した場合の計算です。

i3.16xlarge ノードのインスタンスストアボリュームは 8 x 1,900 GB (15.2 TB) = 13.82TiB となります。そのためノード数は5つくらい…と言いたいところですが前述の通りオーバーヘッドがかなりあるので、実際にはノード数はもっと必要になります。

オーバーヘッド込みの必要なストレージ容量の計算方法はこちらで述べられている通り、

Source Data * (1 + Number of Replicas) * (1 + Indexing Overhead) / (1 - Linux Reserved Space) / (1 - Amazon ES Overhead) = Minimum Storage Requirement

になります。Indexing Overhead(約10%)、Linux Reserved Space（約5%）、Amazon ES Overhead(約20%)を計算すると少し複雑になるので、シンプルな計算式も用意されています。どちらの式でも、ほぼほぼ同じ結果が得られます。

Source Data * (1 + Number of Replicas) * 1.45 = Minimum Storage Requirement

シンプルな計算式で計算してみましょう。1つのレプリカを含むプライマリノードで考えると、以下のようになります。

60TiB * (1 + 1) * 1.45 = 174TiB

約174TiBが必要となります。i3.16xlarge ノードのインスタンスストアボリュームで割ってみると、以下のようになります。

174TiB / 13.82TiB = 12.59

ということで、約13台のノードが必要そうであることが分かりました。i3.16xlarge のノードの時間料金はこちらに記載があるように、バージニア（US-East1）の場合 1 時間あたり 7.987USD となります。13台稼働させると以下のような計算式になります（一月を30日で計算）。

7.987 USD * 24 hours * 30 days * 11 instances ≒ 63,257 USD

Ultra Warm Storageの場合

次にUltra Warm Storageの場合です。

まずストレージ料金についてです。ストレージ料金については一律 0.024USD/per GB per month となります。これはS3 標準に近しい料金設定になります。60TiBをフルに使った場合は以下のように計算になります。

61,440 GiB (60TiB) * 0.024 USD ≒ 1,475 USD

まずインスタンスの時間料金がかかります。インスタンスは2種類から選べるようになっています。

Instance type	vCPU	Memory (GiB)	Maximum Managed Storage per Node (TiB)	Price per Hour
`ultrawarm1.medium.elasticsearch`	2	15.25	1.5	0.238USD
`ultrawarm1.large.elasticsearch`	16	122	20	2.68USD

今回は ultrawarm1.large.elasticsearch を3台稼働させた場合で考えてみます。以下のような計算になります。

2.68 USD * 24 hours * 30 days * 3 instances ≒ 5,789 USD

ストレージとノードを合わせると 7,264 USD になります。Hot Storageの場合の料金と比較すると約87%安くなることが分かります。

すべてをUltraWarm Storageに格納すれば良い訳ではない

一見すると、すべてのデータをUltraWarm Storageに格納すれば良いようにも見えますが、そういう訳ではありません。あくまでホットではないデータを格納する場所としての提供の意味合いが大きいです。Hot Storageに格納した方がスピーディにアクセスできるため、頻繁にアクセスしたり新しいデータはHot Storageの方が適切です。

実際にはアクセスする頻度や期間に応じて、自身でライフサイクルを決めてHot Storageに格納するのかUltraWarm Storageに格納するのかを決めていく必要があります。ハイブリッドになるため、それぞれの計算方式を組み合わせる必要があると思います。